COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.require "let.pub" source file
C00011 ENDMK
C⊗;
.require "let.pub" source file;
.<<
.FONT 1 "basl30"; TURN ON "%";
.FONT 2 "BASI30";
.FONT 3 "basb30";
.FONT 4 "sta200";
.FONT 5 "ngb25";
.>>
∂AIL Dr. J.C.R. Licklider↓Director, Information Processing Techniques↓
Advanced Research Projects Agency↓1400 Wilson Blvd.↓Arlington, VA 20009∞

Dear Lick:

	I have just come upon your memo entitled "Standard DoD High Order
Language", and I have the following comments:

	1. While I have not spent much time reading the document, I am in 
general agreement with its specifications.  I also agree that a general
purpose high order language is a reasonable objective.

	2. The specifications will be difficult to meet, and it will be
difficult to establish that they have been met.
Moreover, the specifications as written will not insure that the language
will meet the intent of the specifications.
%3DoD shouldn't give up
on this account but should prepare for a long and expensive development
with reasonable assurance that the result will be worth the cost.%1

	3. DoD should learn from the previous attempts to specify languages,
e.g. COBOL, ALGOL, and PL/I.  What it should learn may be a matter of
controversy, but here are my ideas:

		a. It is insufficient to form a committee and let the
committee meet several times and specify the language.  It is especially
bad if the committee meetings take the form of logrolling wherein various
members campaign to get features they like into the language.  This may
work out especially badly if the committee members can claim to represent
service interests that have to be taken into account.  What if the Navy
"representative" claims that shipboard programs require "dynamic own
arrays" or some such nonsense, i.e. he will be using his service connection
to support his own ego.

		b. There should be an open competition to prepare complete
specifications perhaps supported by implementations.  Then a committee
should choose one of the rivals, perhaps with the incorporation of features
from rivals.  This increases the probability of arriving at a unified
conception rather than a camel (horse designed by a committee).

		c. The language should not be released for use until
an implementation has been certified to meet the specifications.
.next page
	4. The specification that the object code should be efficient is
too vague.  Here are a few more precise specifications.

		a. The run-time fixed code should not be too large.
In particular, the user defined data structures proposed suggest a
complex storage control and garbage collection mechanism.  It should be
specified that this machinery not be present in runtime code unless its
features are used.

		b. A trivial program should run in trivial time and should
also compile in trivial time.  Many IBM systems that give good results on
large programs fail this one with the result that it is very expensive
to debug subroutines.

		c. A large number of special cases should be compiled efficiently.
For example, a program doing numerical calculations on unsubscripted real
variables should produce code no worse than Fortran.  The problem is that
a compiler for a very general language may produce very bad code for simple
cases.  In the case of ALGOL 60, this was forced by the language, and
some of the ways in which ALGOL 60 loses have been excluded in these specifications,
but a collection of favored special cases needs to be implemented.
Another example concerns subroutine calls.  In the general recursive case,
a stack is required, but in simple FORTRAN like cases, more efficient
subroutine calling is possible.

	Since the language admits recursively defined data structures, it
will include LISP as a special case, but it is not likely that the resulting
LISP code would be efficient in either time or space unless this were an
objective.

	5. The features of the language allowing a program to interact with
a terminal and and with files should be specified in the language, and
should not be installation dependent.  Otherwise, programs will not be truly
portable.  The opportunity can be taken to specify a national file naming
scheme so that programs can refer to files in other computers.

	6. I would like to see dynamic precision for numbers, because I
think this will be easier to use and specify than the maze of single and
double precision numbers now used.

	7. The definition of variable, and the phrase "mathematically
complete in the Turing sense" lead me to worry that the writer of these
specifications, while clearly a sensible person, may not have the mathematics
he is referring to under complete control, and this will later lead to
the discovery that there has not been a complete meeting of minds.

	8. The specifications make no bow towards the ability to prove
programs correct.  For this purpose, it is important that the language
have as simple a formal description as is compatible with the general
features to be provided.  The IBM PL/I formal description shows that
what may seem to be a minor decision to the committee or report editor
may produce major anomalies in the semantics of the language.  These
anomalies show up in the implementation and also when formal definition
is attempted.
.next page
	Therefore, I would argue that the axiomatic definition referred to
in the document be a formal interpreter semantics.

	I hope these remarks are of some use, and would be glad to help
further.

.sgn